Cream of the Crop 1/Cream of the Crop 1.iso/PROGRAM/TP121392.ARJ/12-13-92.TPC

Text File | 1992-12-13 | 53KB | 1,617 lines

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-07-92 07:00:22
From       Trevor Carlsen
To         Gregory P. Smith
Subject    30/11/92 Contest




 TC> The code submitted must be compilable using TP6 or TP7 using
 TC> standard Borland units and must be adequately commented or
 TC> documented.

 GS> Does this mean that it has to compile under both?  Otherwise
 GS> would we be allowed to use TP/BP 7's new Strings unit?

No, it does not need to compile under both versions. As long as it compiles
under one or the other and will run on an 8088, you may use any unit supplied
by Borland with the standard package.

Good luck,

  TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/08  08:26:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-07-92 07:17:11
From       Trevor Carlsen
To         Bob Swart
Subject    Contest



 BS> Today I have send you a 720K disk with my (first)
 BS> submission, called BOBSORT version 1.0 (always modest, this
 BS> guy ;-). It sorts up to 1,048,575 strings.

Top stuff!!  I await it with interest.

 BS> Once you have received my disk, could you please return it
 BS> with *your* program on it? Also, could you post my results
 BS> on your machine (I don't care if anybody else knows how I'm
 BS> doing, so if you want you can just put it in this area ...

I will be happy to do this for you or anybody else for that matter.  It may
not happen overnight however as I am very fully occupied at the present time
with negotiations on the purchase of another business.  If the negotiations
come off I will also be moving house and so may be absent from the echo for
a week or two.

I will keep the echo participants fully informed of my new telephone numbers,
address etc if it becomes necessary to do so.

TeeCee


--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/08  08:26:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-07-92 20:06:48
From       Trevor Carlsen
To         Steve Connet
Subject    Screen memory



 SC> ...The other day (after I wrote the original message) I
 SC> learned about the MEM function.  So then I thought that it'd
 SC> be easier (and faster) to use this and store it in a buffer.
 SC> No prob... but I never learned about pointers.  The books I
 SC> have on TP that go over pointers are horrific.... no
 SC> straight and simple discussion.  I'd like to ask you about
 SC> what you wrote so I can learn them quickly.  You have:

 SC> VAR ScreenBuffer:^Array [0..1999] of Byte;

 SC> From what I understand, ScreenBuffer stores a 32-bit address
 SC> that points to the Array and takes up only 4 bytes of
 SC> memory.  Is this right?

Yes that is correct.

 SC> Now you have:

 SC>  for i:=0 to 1999 do
 SC>   ScreenBuffer^[i]:=mem[$B800:i];
 SC>   { Saves screen to ScreenBuffer }

 SC> Does the 32-bit address in ScreenBuffer automatically change
 SC> to correspond to the variable i?

No it does not.  ScreenBuffer's value remains constant unless the program
specifically changes it; the variable i alters the screen memory location
by indexing an array.

 SC> For example, if i=0 ScreenBuffer will hold an address
 SC> pointing to mem[$b800:0] ... but when i=1 will ScreenBuffer
 SC> contain a new 32-bit address that points to mem[$b800:1]?

When ScreenBuffer is dereferenced the address refers to the starting address
of an array of 2000 bytes.  The variation in where you are looking occurs
solely by the indexing of that array.

 SC> About the video screen: mem[$b800:$0000] contains the
 SC> character and mem[$b800:$0001] contains the attribute for
 SC> offset $0000, and so on. Since 'var i' is a word, it'll hold
 SC> both character & attribute.

i is purely being used as an array index variable.  It does not hold anything
other than the index value.

 SC> But is 2000 enough to store the entire screen?   I know
 SC> 80x25=2000 ... but I think when I tried it, it only did half
 SC> the screen (in mode 80x25).

And here you discover the problem... The 80x25 screen is not made up of 2000
bytes but of 4000. This can be represented by 2000 words or better still of
2000 2 byte records as demonstrated below.

I have quoted almost your whole message as it raises quite a few questions
and for someone just starting out shows a remarkable grasp of the situation.


As you have discovered, CP's original advice was wrong. I would have corrected
this at the time but it was so fundamental that I felt sure others would pick
him up on it and I was very busy! :-(

The following is a little demonstration that will work and it will demonstrate
what you want.

type
  Video_Cell  = record
                  ch   : char;
                  attr : byte;
                end;
  Video_Array = array[1..25,1..80] of Video_Cell;
  { better than array[0..1999] of Video_Cell as it permits referencing the }

  { screen in exactly the same manner as the GotoXY procedure              }


  Video_Ptr   = ^Video_Array;

const
  VideoSeg    : array[0..1] of word = ($b800,$b000);

var
  Screen      : Video_Ptr;
  BlankScreen,
  SavedScreen : Video_Array;

The first thing that must be done is to initialise the pointer that contains
the address in memory where the program expects to find the video screen so
call the following procedure as the first, or one of the first, statements
in your program.

  procedure Initialise;
    begin
      Screen := ptr(VideoSeg[LastMode div 7],0);
      FillChar(BlankScreen,sizeof(BlankScreen),0);
    end;

Once this is done you can store a screen just by -

  SavedScreen := Screen^;

Or to restore a saved screen -

  Screen^ := SavedScreen;

Or to blank or unblank a screen -

  procedure BlankOutScreen(blank: boolean);
    begin
      if blank then {blank out the screen } begin
        SavedScreen := Screen^;
        Screen^ := BlankScreen;
      end else { Restore the screen }
        Screen^ := SavedScreen;
    end;

I am sure you can play around with that little lot :-).


TeeCee



--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/08  08:26:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 14:16:53
From       Trevor Carlsen
To         Chris Johnsen
Subject    Registers (video)



 CJ>   type
 CJ>     ScreenPtr=^ScreenType
 CJ>     ScreenType=record
 CJ>                  Pos : array [1..80,1..25] of record
 CJ>                                                 ch : char;
 CJ>                                                 at : byte;
 CJ>                                               end;
 CJ>                end;


The array declaration is the reverse to what is required. It should be [1..25,1.
80].  I've always reckoned that gotoXY has its parameters back-to-front. The
above only serves to strengthen that opinion.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/09  12:56:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 14:19:01
From       Trevor Carlsen
To         Todd Blair
Subject    Pointer HeLP



 TB> I would like to know how to remove variables and objects out
 TB> of memory once they are not needed anymore.  I heard that it
 TB> has something to do with pointers.  So, I went to my Tp book
 TB> and looked it up.  I read the whole section on pointers.
 TB> After I was done I couldnt understand a word I had read, I
 TB> read it a second time, but still no luck.  Could some one
 TB> please show me an example of the use of a pointer, and
 TB> explain it.  Thanx I would really appreciate it!

A pointer is a variable that contains a memory address.

The heap is all of that memory allocated by DOS to a program for its use that
has not been used by the program for its code, global data or stack.

Dynamic variables are variables that have had space allocated for them on
the heap.

Dynamic variables have no identifier (are unnamed).  Because of this they
need an associated variable that can be used to find where they reside in
memory. Pointers are ideal for this but need some method to define what type
of data it is that they are pointing at.  Pascal provides this method.

  type
    Str10Ptr = ^string[10];
  var
    S : Str10Ptr;

In the above example S is a pointer that has been defined as pointing to an
address in memory that will contain (or should contain) data of type string[10].

However how does S get this value?  How does it know where that data's address
is supposed to be?  Well until the programmer allocates memory for that data
S's value is undefined, so it could be literally pointing anywhere. So it
is *vital* that before we try to use it to use/assign data from/to that memory
location we give S a memory address that is not being used for any other purpose
at the moment and that is big enough to hold the data that we want to place
into it - in this case at least 11 bytes.  We do this by -

  new(S);

Pascal has now allocated at least 11 bytes of heap and has allocated S with
the address of the FIRST byte of that allocation.

Ok... so far so good! How do we access that data (remembering that it has
no name).  Well we "dereference" the pointer. This is done by placing a carat
sign immediately following the pointer's identifier.

  S^ := 'Todd Blair';

To "reference" a dynamic variable we "dereference" its associated pointer
variable.  We cannot say -

  S := 'Todd Blair';

because S is a pointer and that would be trying to give a pointer a string
type value - a compiler "type mismatch" would occur. So every time we wish
to access that dynamic variable we dereference it.

To delete the dynamic variable once it is of no further use is just a matter of -


  dispose(S);

What this statement does is make the memory used by S^ available to be used
for other purposes by the program.  It does not erase the contents of that
memory and it does not give S a new value.  However any attempt to dereference
S is an error as the integrity of that memory location has been lost - it
may have been allocated to other data.

Pointers do not *have* to point to a memory location in the heap or even have
their value always allocated by using the New procedure. Any valid memory
address can be assigned to them and then they can be dereferenced as shown
above.  As a simple example of this lets say you want to examine the contents
of the 16 byte area at $40:$f0 (the ICA area). You could -

   type
     ICA_Ptr = ^array[0..15] of byte;
   var
     B       : byte;
     ICA     : ICA_Ptr;

    ICA := ptr($40,$f0);

Now ICA points to the address specified and you can dereference it -

    B := ICA^[10];

Hope that helps get you started into the complex world of memory management
and manipulation using pointers.  There are countless permutations and methods
that can be used.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/09  12:56:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 14:18:42
From       Trevor Carlsen
To         Brian Fleming
Subject    Problem with delay



 BF> i need a DELAY feature that does not use DELAY (it is
 BF> completely unreliable) but uses the time instead...

As you want to use the time, I presume that the maximum resolution of that
method (about 55ms) is not a problem.  So here is a procedure...

procedure delay(t : word);
  { Produces a machine independent delay of approximately (t * .055) seconds }

  var
    time     : longint absolute $40:$6c;
    start    : longint;
    finished : boolean;
  begin
    start := time;
    repeat
      if time < start then    { midnight rollover occurred during the period }

        dec(start,$1800B0);
      finished := (time > (start + t));
    until finished;
  end; { delay }

TeeCee




--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/09  12:56:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 14:19:19
From       Trevor Carlsen
To         Joe Jared
Subject    Help!



 TC> Never tamper with the value of a loop variable within a for
 TC> loop. It can be done but is exceedingly poor practice and
 TC> the problems it can create is illustrated above.

 JJ> In the above example, the above inserted line will 'break'
 JJ> you out of the loop in much the same fashion as 'Goto
 JJ> labelname' does for while do loops.

Yes, but that doesn't alter the fact that such technique is exceedingly PPP.

If such a statement is needed in a for loop, it simply indicates that the
for loop was a bad structure choice in the first place.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/09  12:56:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 14:19:37
From       Trevor Carlsen
To         Brian Swanson
Subject    Turning off screen



 > In many cases, depending on how the spawned
 > programs do their i/o, you can pipe the output to Nul:
 >   SwapVectors;
 >   Exec (GetEnv('COMSPEC'),'/C CALLED >Nul');
 >   SwapVectors;             ^^        ^^^^

 BS> Nope...I tried this already...The program still writes to
 BS> the screen....

In that case you are SOL because it would appear that the child process is
doing direct screen writes which are not redirectable.

TeeCee


--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/09  12:56:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 14:20:01
From       Trevor Carlsen
To         Andrew Makiejewski
Subject    how to get keys



 AM> I want to pass as a parameter to a procedure that will
 AM> indicate what keypresses are valid. I am doing this already
 AM> for regular keys, but I need to be able to list regular keys
 AM> as well as extended key(mostly function keys).

It is this last requirement that makes things a little tricky.  Here is how
I would do it.

Instead of using ReadKey use a little routine that returns a word when a key
is pressed ...

function KeyWord : word; assembler;
  { Returns a word value where the msb is the scan code of a keypress    }
  { and the lsb is the asciiz value of the key.                          }
  asm
    mov  ax,0
    int  16h
  end;  { KeyWord }

Now you can do your validating based on the scan code.  However there is a
catch here as well.  If you do not want a particular character from shifted
keys etc then additional code is needed.

Generally speaking, I would think  a simple case statement is best. Have a
look at the KEYINPUT.PAS file in TCSEL*.ARJ (available on PDN nodes) for an
extensive example.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/09  12:56:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-07-92 07:46:36
From       Dj Murdoch
To         Jakob Paikin
Subject    Re: BP 7 Outline bug

  DM>       DisposeNode(ChildList);
 DM>       DisposeNode(Next);
 DM>       DisposeStr(Text);
 DM>       Dispose(Node);

 JP> Is it intentional that you've left out the '<> Nil' checking?

You've misquoted me a bit.  The fragment above is from the DisposeNode procedure
 it starts out as

  if Node <> nil then
    with Node^ do
    begin

Thus DisposeNode already has '<> Nil' checking in it.  So does DisposeStr.
 So all that I've left out are redundant checks.  It might be slightly faster
to leave them in and avoid the far calls, but the big cycle-eater here would
be the actual disposal, so I tend to doubt that the difference would be noticeab
e.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/10  08:10:36

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-07-92 20:33:25
From       Dj Murdoch
To         Matthew Warner
Subject    Re: Turbo Date Advance...

  MW> Has anyone else encountered problems with programs written in Turbo Pascal
 MW> not advancing the date at midnight?  We've tried it on our
 MW> XT and '386 with
 MW> the same results.  Every now and then, the date on the
 MW> system clock will  not
 MW> advance.  These programs -DO- poll the system clock almost constantly for

 MW> timing functions, but no SetDate/SetClock commands are issued.  Any ideas?

How are they polling the system clock?  If they don't use DOS, then a well-
known DOS bug may be to blame:  if you don't ask DOS for the time for an entire
day, it doesn't notice it.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/10  08:10:36

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 00:00:00
From       Terry Hughes
To         Greg Ryan
Subject    B-tree question


GR>TH> X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-9726)
GR>Terry,
GR>  This is your bbs number isn't it? Not voice
GR>Greg

Whoops! You're absolutely right...must have happened a couple of weeks
ago when I upgraded to the latest OLX. Thanks for pointing that out.

-Terry

___
 X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss/286 v1.02a on 92/12/10  23:25:07

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 00:00:02
From       Terry Hughes
To         Greg Ryan
Subject    multitasking


GR>  has Turbo Power ever considered writing a multi-tasking library...i'd
GR>  place my order today!
GR>  There seem to be several for C and C++...however the only commercial
GR>  mt'ing lib seems to be from a company in Germany (On-Time). Looks ok
GR>  but is expensive and I don't feel like calling overseas for support

We've thought about it several times. So far, we keep ruling it out for
the following reasons: too small market, high degree of difficulty
in keeping it general enough for common use but robust enough to be
usable, and the variety of alternative solutions (DV and Windows).

Every couple of months I see a small add for some new (or existing) TP
multitasker in the back of Dr.Dobbs or Computer Language. I don't pay
close enough attention to notice how many different ones there are but
I'm sure there's at least 2 or 3 companies offering these things.
You might want to browse through a few back issues of those magazines to
see if you can't find something closer to home.

-Terry

___
 X QMPro 1.0 41-2187 X TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss/286 v1.02a on 92/12/10  23:25:07

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 08:22:09
From       Dj Murdoch
To         Grischa Brockhaus
Subject    Re: Cold Boot in program: ho

  DM> It's rather risky to reboot this way, now that people use caches that
 DM> don't keep the disks up to date.  If you do, you'll
 GB> likely trash someone's
 DM> disk. To do it right, you should do it in a way that
 GB> informs the cache
 DM> that you're about to reboot.  I don't have any code for this.

 GB> But any idea, how to inform a cache ??

One idea I've heard of is to reset the disk.  Another is to fake a Ctrl-Alt-
Del keypress (but of course that's for a warm boot).  Another is to insert
a 5 second delay, since most caches will flush themselves in that time.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/10  23:25:10

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 07:05:10
From       Trevor Carlsen
To         David Muench
Subject    Swapper?



 DM> Does anyone have a unit or code that will replace (well, not
 DM> really) the Exec command but will swap to EMS/XMS/Disk
 DM> before executing the code?

I am not aware of any PD or shareware code for this but Turbo Power's Object
Professional library certainly contains such a beast.  Top quality product
this, good value and you get full source. Comes with about 1600+ pages documenta
ion in 3 manuals and is recommended to any serious programmer.  Check out
the computer mags for sources.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 07:09:23
From       Trevor Carlsen
To         Daniel Mecklenburg
Subject    Real <--> float/double



 DM> I'm looking for either code in Pascal or C or the structures
 DM> (bit wise) or algorythms for converting Pascal Reals to and
 DM> from C's floats and doubles.

Turn on 8087 emulation and instead of Real, use the types that are the equivalen
 -

    single
    double.

So you can directly read a C float type into a TP single type. I might add
that I have never actually tried this but reading the manuals would appear
to indicate that it will work.

TeeCee


--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 07:28:20
From       Trevor Carlsen
To         Derek Finlay
Subject    Rounding real numbers??



 DF> Round_Off := Imperial_Weight * Decimal_Mover;
 DF> Round (Round_Off : real);
 DF> Imperial_Weight := Round_Off / Decimal_Mover;

Actually you are on the right track!  It just looks like you misunderstand
how to use the round function.  In the second of the three above lines of
code change the statement to -

      Round_Off := Round(Round_Off);

Actually the whole three lines could be expressed as -

  Imperial_Weight := round(Imperial_Weight * Decimal_Mover) / Decimal_Mover;

thus eliminating the need for the variable Round_Off.


TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 09:17:33
From       Trevor Carlsen
To         All
Subject    ECHOCOP



Echocop is temporarily off-line here for further development and modification.


Thanks to those "victims" who have responded so favourably and to those who
have submitted positive criticisms along with suggestions as to how it could
be improved. They have been noted and some, if not most, of those suggestions
will be incorporated when it is next used.

And to those of you who don't know what the hell I am talking about - thanks
for staying within the guidelines of this echo!

Moderator

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 07:52:57
From       Trevor Carlsen
To         Mike Copeland
Subject    Record Fields to Text File



 SM> I am trying to read in specific fields from a record and
 SM> write them to a text file with no success. This is how I'm
 SM> trying to do it:

 SM>  While Not EOF( recordfile ) do begin
 SM>    read( recordfile, data )
 SM>    With  data do begin
 SM>      Write(textfile, field)

 SM> Is this even close or can it simply no be done?

 MC> It's pretty much off the mark, as you are combining the use
 MC> of user-defined structures (with the "with") and text file
 MC> processing, which need not use that concept.  In other
 MC> words, it seems you are trying to intermix concepts you
 MC> don't understand well.  8<}}

I think that you have misunderstood the question Mike; certainly your response
would indicate that as it does not tie in with the request.  I see nothing
wrong with what he is trying to do except that when writing to the text file
he should probably be using writeln.

The lack of success is puzzling as the little code provided appears OK along
with its logic.  The problem must lay in code away from what we have be shown.

TeeCee



--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 08:00:04
From       Trevor Carlsen
To         Steve McKain
Subject    Record Fields to Text File



 SM> I am trying to read in specific fields from a record and
 SM> write them to a text file with no success. This is how I'm
 SM> trying to do it:

 SM>  While Not EOF( recordfile ) do begin
 SM>    read( recordfile, data )
 SM>    With  data do begin
 SM>      Write(textfile, field)

 SM>  Is this even close or can it simply no be done?

You do not say what the "no success" is...

There is nothing wrong with the above code or the logic behind it although
it may be that writeln would be better than the write for the textfile. However
that would be dependent on the format you are trying to achieve in the textfile.

I also presume that "field" has indeed been defined as such somewhere or that
you are using this as pseudo code for demonstrating what you are trying to do.


Here is a little (untested) snippet based on what you are trying to do:

type
  User_rec = record
               FirstName,
               LastName  : string[20];
               Age       : byte;
             end;
var
  TypedFile : file of User_rec;
  TextFile  : text;
  user      : User_rec;

begin
  assign(TypedFile,'RecFile.dat');
  reset(TypedFile);
  assign(TextFile,'TextFile.txt');
  rewrite(TextFile);
  while not eof(TypedFile) do begin
    read(TypedFile,user);
    with user do
      writeln(TextFile, LastName, ', ',FirstName,age:4);
  end; { while }
  close(TypedFile);
  close(TextFile);
end.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 08:17:09
From       Trevor Carlsen
To         Matthew Warner
Subject    Turbo Date Advance...



 MW> Has anyone else encountered problems with programs written
 MW> in Turbo Pascal not advancing the date at midnight?  We've
 MW> tried it on our XT and '386

I believe that the problem is not confined to TP; it is a DOS problem rather
than a TP one and is caused (I think) by an interrupt service you are using
calling DOS for the time between the midnight rollover and the date change
routine in DOS. C programs suffer the same problem.

The cure - as far as TP is concerned - is not to use any interrupt service
for determining the time.  Calculate the time from the value stored at $40:$6c
instead.

TeeCee



--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 08:27:13
From       Trevor Carlsen
To         Carl Russell
Subject    Re: Os/2



 CR> In PC mag, Dvorak claims that August will be the earliest
 CR> release date for Win NT...

The subject matter of the above message is unrelated to the subject matter
of this echo.  Take the thread to netmail or cease posting.

If you wish to reply to this message do so by netmail only.

Moderator

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 09:12:18
From       Trevor Carlsen
To         Martin Brewer @ 914/201
Subject    Pascal



 MB> The way that I feel about it is, when you pay that kind of
 MB> money for a school, your buying everything that that's
 MB> inside the school.

That is naive, ridiculous and illegal. Software copied in that way is stolen
- plain and simple - STOLEN.  If you had said you considered that after paying
that kind of money you believed they should have provided you with a free
LEGAL copy, I would have no complaints and would probably agree with you.
However your feelings do not make something lawful - the law decides that.
Your feelings would also not be considered in a court.

Take this thread to netmail if you wish to continue it.  Do not post any further
messages on the subject in this echo.

Moderator

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 08:56:48
From       Trevor Carlsen
To         Steve Connet
Subject    Hot Key...



 SC> You know what I found out when playing with this is that
 SC> MEM[$0:$0418] equals 2 when the left ALT key is pressed,
 SC> regardless of any other key that is active.

Pressing left alt only sets bit 1 at that address.  If no other bits are set
then the value will obviously be 2. However if other bits are set - caused
by pressing NumLock, SysReq, CapsLock, Insert, Pause, ScrollLock or LeftCtrl
at the same time as when you press LeftAlt then your value will not be 2.
 For proof run this -

uses crt;
var
  keystate : byte absolute $40:$18;
begin
  clrscr;
  repeat
    gotoXY(1,1);
    write(keystate:4);
  until keystate > 127;
end.

Now while pressing left alt also press num lock or scroll lock or caps lock etc.

Program terminates by pressing the insert key.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 22:31:17
From       Dj Murdoch
To         Jason Huebel
Subject    Re: borland pascal 7.0

  JH> Thanks for the reply, I wish TP were going to create
 JH> .OBJ's... But you can't win them all. :) I'm not going to
 JH> buy BP since it's a little outta my price range. But I
 JH> intend on getting TP 7.0 soon, so I won't be too far
 JH> behind everyone else. Again, Thanks for the reply.

One thing I didn't mention:  BP 7 can produce .DLLs, but TP 7 can't.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:44

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 22:33:34
From       Dj Murdoch
To         Robert Roland
Subject    Re: v7.0 .TPU files

  >>JM    Recompiling from the original source is the only way.

 > That's what I was afraid of. :-(

 > Dave

 RR> Don't you think Borland should make an upgrade program for that? :)

They do - the compiler.  Just feed that old source code through it, and out
come the new .TPU files.  Don't have the source code?  Then throw out the
.TPU.  If it's not causing you trouble now, it'll cause you trouble later.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/11  08:04:44

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 22:31:11
From       Dj Murdoch
To         Jason Huebel
Subject    Re: borland pascal 7.0

  JH> Thanks for the reply, I wish TP were going to create
 JH> .OBJ's... But you can't win them all. :) I'm not going to
 JH> buy BP since it's a little outta my price range. But I
 JH> intend on getting TP 7.0 soon, so I won't be too far
 JH> behind everyone else. Again, Thanks for the reply.

One thing I didn't mention:  BP 7 can produce .DLLs, but TP 7 can't.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)

--- FidoPCB v1.1 [FF014]
 * Origin: La. Medsig - A Medical BBS since 1983 - Harahan, La (1:396/28)
 * Tossed by SFToss/286 v1.02a on 92/12/12  08:07:22

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-08-92 22:33:11
From       Dj Murdoch
To         Robert Roland
Subject    Re: v7.0 .TPU files

  >>JM    Recompiling from the original source is the only way.

 > That's what I was afraid of. :-(

 > Dave

 RR> Don't you think Borland should make an upgrade program for that? :)

They do - the compiler.  Just feed that old source code through it, and out
come the new .TPU files.  Don't have the source code?  Then throw out the .TPU.

 If it's not causing you trouble now, it'll cause you trouble later.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)

--- FidoPCB v1.1 [FF014]
 * Origin: La. Medsig - A Medical BBS since 1983 - Harahan, La (1:396/28)
 * Tossed by SFToss/286 v1.02a on 92/12/12  08:07:22

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 20:09:15
From       Dj Murdoch
To         Joe Jared
Subject    Re: Segment alignment

  JJ> The following practice will keep your heap^ segment
 JJ> aligned, which will make Basm, as well as inline coding
 JJ> much simpler when programming with Turbo Pascal.
 JJ> Hopefully someday Borland will drop the :8 address and
 JJ> just give us a Segment per allocation, as it would make
 JJ> everyone's life much easier, and eliminate the most
 JJ> irritating bug in their software, and expand the capacity
 JJ> of heap alignment to 65535 bytes.

Just use MemAllocSeg if you want to allocate a segment aligned pointer.  It's
in the Memory unit in TP 6 or 7.  Borland gave it to you, you just didn't
notice.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/12  08:07:51

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 20:12:50
From       Dj Murdoch
To         Christian Brem
Subject    Re: BP 7.0 and Turbo Vision

  CB> I have heard, that in TP 7.0 there will be no Turbo Vision
 CB> but something similar and compatible to Windows (?).
 CB> Is this true -have I to rewrite all Programms developed in
 CB> TP 6.0 using Turbo Vision ?

No, you get an updated version of Turbo Vision.  I haven't noticed any incompati
ilities with the old one, but I'm sure there are a few hiding in there.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/12  08:07:51

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 21:15:11
From       Dj Murdoch
To         Bob Swart
Subject    Re: Strange Behaviour of Redirection, or

  BS> I just noticed a strange behaviour of redirection with
 BS> Turbo Pascal 6.0 (but maybe it's just my old head that needs some rest :).


 BS> The program below demonstrates the 'feature':

 BS> var f: Text;
 BS> begin
 BS>   writeln('1. Usage: BUG [>output]');
 BS>   Assign(f,'');  {stdout}
 BS>   rewrite(f);
 BS>   writeln(f,'2. This can be redirected.');
 BS>   close(f);
 BS>   writeln('3. last line');
 BS> end.

That's a pretty strange thing to be doing in a program -- it's not a good
idea to have two text variables attached to the same file.  In your particular
case, you get the strange output because of a couple of things interacting:


  1.  TP buffers text files, and only writes things when the buffer (usually
      128) bytes is full, or you flush or close the file.
  2.  TP doesn't buffer writes to the console; or rather it acts as though the

      buffer size is 1.

So when your program is not redirected, rule 2 means that all I/O shows up
in the expected order.  When you do redirection, here's what happens:

  1.  The first writeln goes into the buffer in the Output variable.
  2.  The second writeln goes into the buffer in the  f  variable.
  3.  Close(f) forces  f  to be flushed, which makes line 2 show up.
  4.  The last writeln goes into the Output buffer.
  5.  The end of your program closes Output, and lines 1 and 2 get flushed.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/12  08:07:51

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-09-92 21:23:52
From       Dj Murdoch
To         Max Maischein
Subject    Re: Debug data format / Map file convers

  MM> Does anybody have a documentation for the debug data
 MM> tacked at the end of each .EXE file under TP ( if $D+
 MM> specified in the source ) ?

It's described in the "Open Architecture" book that came with (or was optional
with) BC++ 3.1.  I've heard that a BP specific version is planned, but I haven't
heard a publication date.



--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/12  08:07:51

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-12-92 06:53:00
From       Trevor Carlsen
To         Larry Edwards
Subject    Single List Help



 LE> ...Right now I do something like "DIR>>Dir.Txt", then I go
 LE> into that file and extract the file names and extensions,
 LE> and write them out to another file. What I would like to do
 LE> is something like using a Single List to keep the contents
 LE> of the directory in memory and use that later in the
 LE> program. The only part I am interested in is the file name
 LE> and extension. I know using FindFirst and FindNext will pull
 LE> the file names but that is where I run out of knowledge. The
 LE> Big problem I see is that I do not know the number of files
 LE> in a directory, so I can't use an Array, that brings me to a
 LE> Single List.

I *would* use an array for what you are doing, although a linked list would
also be quite valid here if memory was really tight or no further manipulation
or random access of the data is needed.  However it would be an array of pointer
 and the actual names can be dynamically stored.  That way you can manipulate
(sort) the list to your heart's content.  The file TCSEL*.*  (available PDN
nodes) contains a simple directory program that may help you a little but
here is a brief (untested) example of what I mean.

uses
  dos;

const
  MaxFiles = 1000; { Alter to suit }

type
  FName    = string[12];
  FNPtr    = ^FName;
  FPList   = array[1..MaxFiles] of FNPtr;

var
  dirInfo  : SearchRec;
  list     : FPList;
  fileName : FName;
  NumbFiles,
  count    : word;

begin
  { First initialise the array of pointers to Nil }
  FillChar(list, sizeof(list), 0);

  NumbFiles := 0;
  count     := 0;

  FindFirst('*.*',AnyFile,dirInfo);
  while DosError = 0 do begin

    { Filter out directories etc }
    if ($18 and dirInfo.Attr) = 0 then begin

      { Allocate memory for the name and extension }
      inc(NumbFiles);
      new(list[NumbFiles]);

      { assign the name to the list element }
      list[NumbFiles]^ := dirInfo.Name;

    end; { if ... }
    FindNext(dirInfo);
  end; { while DosError ... }

  { Display the list of names }
  if NumbFiles <> 0 then repeat
    inc(count);
    writeln(list[count]^);
  until count = NumbFiles;

end.

If you compile and run that and I haven't made any stuff-ups :-), it will
display all the file names in the current directory.


TeeCee


--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:26

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-12-92 06:46:00
From       Trevor Carlsen
To         Steve Connet
Subject    Screen memory



 SC> ... And I intently read the short tutorial on pointers you
 SC> gave to Todd Blair.  I do not completely understand it but I
 SC> think I have a fair enough understanding of it to work with
 SC> it.

You have just completely destroyed my ego! :-)  I tried very hard to make
that a very fundamental and easy-to-understand explanation. Oh well, back
to the drawing board...

 SC> However, I still have somewhat of a phobia with "Linked
 SC> Lists."...

Linked lists are a reasonably complex subject. I firmly believe that they
are "overused" and that this overuse comes about because in classes the demonstr
tions of their use often use applications that are not necessarily ideal for
the technique - just convenient and simple.  Don't get me wrong, linked lists
and the familiarity with the techniques involved in their use are a vital
part of programming skills.  Just don't get the idea that they are the only
use there is for pointers!

 SC> ... Say I have a record with a name, address, and a linker
 SC> to point to the next record.  Do I have to use the NEW
 SC> procedure to expand the linked list (to add new records)?

Yes you do.  Everytime you wish to expand a linked list the last pointer in
the link needs a new valid address to the record you are adding to the list
and that new record needs memory to be reserved for it to reside in. This
memory must be allocated and the "linker" given its address by the new() procedu
e (although in TP there is another procedure - GetMem - as well.  I would
not worry about that though until you have the concepts of pointers, linked
lists and the like down pat.).

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:26

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-12-92 07:05:00
From       Trevor Carlsen
To         Tom Lawrence
Subject    Fast Direct screen writess



 > the only fast way to achieve this is to go into asm and doing the
 > thing directly. Pascal uses the BIOS to output the text, so it is
 > SLOW.

 TL>     Not true.  Turbo Pascal, by default, writes directly to VIDRAM,
 TL> bypassing BIOS writes.  You can force it to write to BIOS by setting

 TL> DirectVideo to FALSE.

By default Turbo Pascal uses DOS to do all its screen writing - it does NOT
write directly to the VIDRAM.  However...

If the CRT unit is used then your statement is correct.

TeeCee



--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:26

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-12-92 07:16:00
From       Trevor Carlsen
To         Rainier van.Slingerlandt
Subject    Word-Wrap !!



 Rv> Is there someone out there that has a routine for using word-wrap

This qualifies as a FAQ and the following answer is being added to the A2FAPQ
file in TCSEL003.* uploaded to PDN today.

Here is a program that demonstrates both word wrap and justifying.

var
  S : string;

function Wrap(var st: string; maxlen: byte; justify: boolean): string;
  { returns a string of no more than maxlen characters with the last   }
  { character being the last space before maxlen. On return st now has }
  { the remaining characters left after the wrapping.                  }
  const
    space = #32;
  var
    len      : byte absolute st;
    x,
    oldlen,
    newlen   : byte;

  function JustifiedStr(s: string; max: byte): string;

    { Justifies string s left and right to length max. If there is more }
    { than one trailing space, only the right most space is deleted. The}
    { remaining spaces are considered "hard".  #255 is used as the char }
    { used for padding purposes. This will enable easy removal in any   }
    { editor routine.                                                   }

    const
      softSpace = #255;
    var
      jstr      : string;
      len       : byte absolute jstr;
    begin
      jstr := s;
      while (jstr[1] = space) and (len > 0) do   { delete all leading spaces }

        delete(jstr,1,1);
      if jstr[len] = space then
        dec(len);                                { Get rid of trailing space }

      if not ((len = max) or (len = 0)) then begin
        x := pos('.',jstr);     { Attempt to start padding at sentence break }

        if (x = 0) or (x =len) then       { no period or period is at length }

          x := 1;                                    { so start at beginning }

        if pos(space,jstr) <> 0 then repeat        { ensure at least 1 space }

          if jstr[x] = space then                      { so add a soft space }

            insert(softSpace,jstr,x+1);
          x := succ(x mod len);  { if eoln is reached return and do it again }

        until len = max;        { until the wanted string length is achieved }

      end; { if not ... }
      JustifiedStr := jstr;
    end; { JustifiedStr }


  begin  { Wrap }
    if len <= maxlen then begin                       { no wrapping required }

      Wrap := st;
      len  := 0;
    end else begin
      oldlen := len;                { save the length of the original string }

      len    := succ(maxlen);                        { set length to maximum }

      repeat                     { find last space in st before or at maxlen }

        dec(len);
      until (st[len] = space) or (len = 0);
      if len = 0 then                   { no spaces in st, so chop at maxlen }

        len := maxlen;
      if justify then
        Wrap := JustifiedStr(st,maxlen)
      else
        Wrap := st;
      newlen :=  len;          { save the length of the newly wrapped string }

      len := oldlen;              { and restore it to original length before }

      Delete(st,1,newlen);              { getting rid of the wrapped portion }

    end;
  end; { Wrap }

begin
  S :=
'By far the easiest way to manage a database is to create an '+
'index file. An index file can take many forms and its size will depend '+
'upon how many records you want in the db. The routines that follow '+
'assume no more than 32760 records.';

while length(S) <> 0 do
  writeln(Wrap(S,60,true));
end.

Whilst this is tested and known to work on the example string, no further

testing than that has been done.  I suggest you test it a great deal more

before being satisfied that it is OK.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:26

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-12-92 10:39:00
From       Trevor Carlsen
To         Brandon Jones
Subject    Os/2



 BJ> Yeah I have the OS/2 beta

I have previously requested several times that this thread be moved to an
appropriate area.  This conference is for discussing Pascal - not OS/2, DOS
or any operating system.  Consider this to be a final warning.

If you wish to reply to this message do so by netmail only.

Moderator.

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:26

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-10-92 08:04:00
From       Dj Murdoch
To         Mike Copeland
Subject    Re: Array of Pointers

  MC> used: TP6.0+ operates differently that TP5.5-.  That's
 MC> because TP6.0 allocates memory in mod-16 byte chuncks - so
 MC> allocating 9 bytes for the String[8] would truly _use_ 16
 MC> bytes of the Heap, which would be a terrible waste in this
 MC> specific case.  TP5.5- allocates just the 9 bytes.

Actually, TP6+ uses mod 8 chunks - but the effect is the same. Seven bytes
get wasted in this allocation.  However, there's a big advantage to the TP
3/6+ scheme over the 4/5.x scheme.  A deallocation is guaranteed to increase
free space, and it's guaranteed to succeed.  If you call Dispose in 4/5.x
and create a new block of free heap space, the heap manager has to allocate
a new 8 byte record to describe it.  If it can't do that, you get a "heap
overflow" error on a *de*allocation.  In the current scheme, the record is
stored in the space that was just freed up, which is guaranteed to be at least
8 bytes.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:38

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-10-92 08:10:00
From       Dj Murdoch
To         Trevor Carlsen
Subject    Re: Turbo Date Advance...

  TC> The cure - as far as TP is concerned - is not to use any
 TC> interrupt service for determining the time.  Calculate the
 TC> time from the value stored at $40:$6c instead.

That just gives you the time of day, not the date.  The BIOS doesn't keep
track of the date (except in the real-time clock, which is rather slow to
query, and a flag to indicate that midnight has been passed at least once).
 As long as you ask DOS for the time at least once a day, it keeps the date
updated correctly.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:38

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       12-10-92 08:16:00
From       Dj Murdoch
To         Nathan Wambach
Subject    Re: pascal uncompileer

  NW>         Which leads ME (my opinion) to believe that you can then convert
 NW> the ASM into PAS...  Wouldn't be easy, and you sure wouldn't get the
 NW> exact same code as the writer uses...  but I think it would work...
 NW> After all, you can use ASM in Pascal...  Who knows?  They would never
 NW> release a program to covert EXE/COM to PAS!  (again, my opinion)

Of course you can convert the assembler into Pascal, but it wouldn't be any
more informative than the assembler was.  Which do you find clearer:

The original program:

const
  screenwidth=80;
  screenheight=24; var
  x,y:byte;
  vscreen : array[1..24,1..80] of word; begin
  vscreen[10,20] := 0; end.

The disassembly:

  0000:0000 9A00000200      CALL    0002:0000
  0000:0005 55              PUSH    BP
  0000:0006 89E5            MOV     BP,SP
  0000:0008 31C0            XOR     AX,AX
  0000:000A 9ACD020200      CALL    0002:02CD
  0000:000F 31C0            XOR     AX,AX
  0000:0011 A31806          MOV     [DS: 0618],AX
  0000:0014 C9              LEAVE
  0000:0015 31C0            XOR     AX,AX
  0000:0017 9A16010200      CALL    0002:0116

Or equivalent Pascal:

var
  words : array[0..32760] of word; begin
  words[$30C] := 0; end.

What all you decompiler-boosters are missing is the fact that a program tells
the programmer far more than it tells the CPU. If you look at the .EXE, all
you see is what it tells the CPU to do.  You don't get told why.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:249/99.5)
 * Tossed by SFToss/286 v1.02a on 92/12/12  17:51:38